After the 8-digit SWAR block loop in loop_parse_if_eight_digits, a remaining
run of 4–7 digits is currently finished one byte at a time by the caller. This adds
a single 4-digit SWAR step (reusing the existing read4_to_u32 /
is_made_of_four_digits_fast / parse_four_digits_unrolled helpers, already used
elsewhere in the file) to consume four of those digits at once. The parsed result is
identical — it is purely a faster way to consume the same digits.

Benchmark — m8g.metal-24xl (Graviton4 / Neoverse V2), -O3 -march=native,
simple_fastfloat_benchmark, from_chars→double, clang 18, base vs patch
measured back-to-back (reproduced across 3 runs):

About the #if defined(__clang__) gate

I gated this to clang, and I want to be upfront about why rather than hide it. On
gcc the extra 4-digit check regresses inputs whose remainder is shorter than 4
digits (e.g. the 17-digit fraction of uniform [0,1]: gcc spends the check but never
takes it, ~−3% on random), while clang shows no such regression and a large gain on
the mid-length fractions in canada/mesh. Gating keeps the clang win with zero
regression on either compiler, but it does introduce a compiler-specific branch.

I'm happy to do whatever you prefer here: drop the gate (accepting the gcc random
regression), keep it gated, rework it into a form that helps both, or drop the PR if
you'd rather not carry a compiler-specific path. Numbers and reasoning are all here so
you can decide.

Correctness

FASTFLOAT_TEST (14/14) + supplemental corpus + the randomized random_string /
short_random_string tests pass under clang; an exhaustive float32 sweep
(FASTFLOAT_EXHAUSTIVE) is running. Clean C++11/C++20 under
-Werror -Wall -Wextra -Weffc++ -Wconversion -Wsign-conversion; clang-format clean.
No multi-byte reads beyond the existing endian-safe read4_to_u32, so big-endian is
unaffected.